Different users use different types of Mobile data processing Systems (MSs) which are also called mobile devices: laptops, tablet computers, Personal Computers (PCs), Personal Digital Assistants (PDAs), cell phones, automobile dashboard mounted data processing systems, shopping cart mounted data processing systems, mobile vehicle or apparatus mounted data processing systems, Personal Navigational Devices (PNDs), Android enabled devices, iPhones (iPhone is a trademark of Apple, Inc.), iPads (iPad is a trademark of Apple, Inc.), and other various handheld mobile data processing systems, etc. There are many applications which use various message formats to carry out a variety of functionality. Many of these applications intersect in functionality, message formats, and processing. This causes redundant processing and storing of data at a MS which is usually limited in performance, storage capacity and processing power. A method is needed for consolidating, standardizing, or at least organizing overlapping messaging functionality to provide optimal MS processing, storage and performance. The term “message” or “messaging” as used herein is meant to be interpreted in the broadest sense of conveying or communicating information to a recipient user.
A well organized method is needed for enabling users to manage messages (e.g. information for presentation) for any of a variety of reasons that make sense at a MS. Users should be able to make use of saved messages for automating Out-Going Messages (OGMs) such as those played to callers of a phone (e.g. voice) mail system, Out-going Caller Messages (OCMs) which are disclosed as those messages being left automatically to a phone (e.g. voice) mail system, Confirmation Of delivery Messages (COMB) which are disclosed as those messages for automatically distributing based on a previous distribution, and ADvertising messages (ADs) for conveying an advertising information to recipient(s). ADs are useful in many applications involving OGMs, OCMs and COMs, and AD type messages do not have to be advertisements. Providing MS applications with access to a well architected “content-centric” interface gives rise to synergistic functionality quickly incorporated into new applications. Incorporating a content-centric solution enables providing low cost MSs and MS applications through advertisement bills paid by companies seeking novel ways to advertise.
Different systems for email, phone mail and calendaring provide different methods for a confirmation of delivery. For example, one email system will provide a Confirmation Of Delivery (COD) status to the sender when an email arrives to a recipient's in-basket while another will provide a COD status when a recipient opens the email item. Systems may also implement different methods for communicating the status. Some will send a separate COD email (e.g. received as new email in in-basket), and some will require a sender to examine (e.g. poll), or perform user interface actions, for status associated with the email sent. A consistent method is needed across heterogeneous applications and for supporting any application involved in distribution of information between a sender and recipient such as phone applications, address book applications, calendar applications, or any other application involved in inbound or outbound data. Providing a COD status also may be an opportune time to additionally provide an advertisement. An advertising framework should provide enough non-advertising functionality to entice users to use the framework.
The multi-threaded Location Based Exchanges (LBX) MS has the ability to carry out processing which was conventionally carried out by external services. For example, a corporate PBX (Private Branch Exchange) would accept phone mail system messages from callers for unanswered phones, enable user interfaces to retrieve phone mail system messages, enable call waiting, and provide many other useful phone system features. In another example, a MS can incorporate its own call answering service, and save caller recordings like a conventional answering machine. The LBX MS can be self-contained for functionality, and may also interface directly to another MS for phone features which were provided by a service. In particular, as MSs incorporate peer to peer operation, there is no need for services to middle-man functionality. The MSs themselves contain adequate processing power and LBX multi-threaded capability to provide necessary processing for functionality which was conventionally provided by a service. Therefore, a method and system is needed for centralizing common messaging interfaces across a plurality of heterogeneous LBX MS applications. Leveraging third party advertisement budgets for such functionality is desirable.
While LBX is a preferred embodiment, telecommunications companies are reluctant to give up control of phone user interactions and billing conversation enablement. Even two MS users standing next to each other may be required to go through their phone company network processing in order to have a conversation using their MSs. In the LBX architecture, two users standing next to each other can make use of a direct wireless peer to peer LBX connection to accomplish their connectivity. IP datagrams (e.g. WDRs (i.e. Whereabouts Data Records or Wireless Data Records)) or a validated-delivery protocol of WDRs may be exchanged between the MSs for carrying out data exchanges or conversations, for example one channel for carrying data from the caller to the callee and another channel for carrying data from the callee to the caller. Therefore, the disclosed method and system must handle traditional telephony (e.g. cellular) environments as well as LBX peer to peer communications environments.